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REMARKS 

Claims 22-35 are amended. No claims are cancelled. No new claims are added. Claims 
1-35 are now pending in the application. The amendments to the claims as indicated herein do 
not add any new matter to this application. Furthermore, amendments made to the claims as 
indicated herein have been made to exclusively improve readability and clarity of the claims and 
not for the purpose of overcoming alleged prior art. Each issue raised in the Office Action 
mailed April 13, 2007 is addressed hereinafter. 

I. ISSUES NOT RELATING TO PRIOR ART 

A. DRAWINGS 

The drawings were objected to under 37 CFR 1.84(p)(4) because reference characters 
"222" and "228" were used to designate the same path. The enclosed Replacement Sheet for 
Figure 2A by labels an unlabeled path as "226" and labels the path formerly labeled "226" as 
"228". 

The drawings were objected to under 37 CFR 1.84(p)(5) because the reference characters 
"606" and "602B" were not mentioned in the description. Paragraphs 95 and 108 listed in this 
response use the reference characters. 

The drawings were objected to under 37 CFR 1.121(d) due to an unlabeled line between 
#208 and #210. In the replacement sheet for Fig. 2A, the unlabeled line is labeled as "226". 

The drawings fully comply with 37 CFR 1.84(p)(4), 37 CFR 1.84(p)(5), and 37 CFR 
1.121(d). Reconsideration is respectfully requested. 

B. CLAIMS 22-35 FULLY CONFORM TO 35 U.S.C. § 101 

Claims 22-35 were rejected under 35 U.S.C. § 101 as allegedly directed to non-statutory 
subject matter under the rationale that the subject matter recited by Claims 22-35 may include a 
wave, which is allegedly non-statutory subject matter. 

Present Claims 22-35 are directed towards either a computer-readable storage medium or 
an apparatus comprising a computer-readable storage medium. A wave, such as a carrier wave, 
is not a computer-readable storage medium because computer-readable instructions cannot be 
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stored on a wave; at best, a wave may temporarily carry instructions, which when stored on a 

computer-readable storage medium, may be read by a computer. Accordingly, Claims 22-35 

recite proper subject matter under 35 U.S.C. § 101. Reconsideration is respectfully requested. 

C. CLAIM 1 1 IS FREE OF INFORMALITIES 

Claim 1 1 was objected to as allegedly containing a ""' before the word symptoms on line 
16. It is respectfully submitted that Claim 1 1 was filed with no such informality. Therefore, 
listing the claim as "currently amended" would be improper. The original Claim 1 1 is listed 
above, and contains no informalities. 

II. ISSUES RELATING TO PRIOR ART 
A. CLAIMS 1-35 

Claims 1-35 are rejected under 35 U.S.C. § 103(a) as allegedly unpatentable over 
Marques. The rejections of Claims 1, 11, 15, 22, and 32 are respectfully traversed. 
CLAIM 1 

Claim 1 recites, in part, "defining and storing a set of rules in one or more Rule-Based 
Markup Language ("RBML") Documents." The Office action asserts that "in regards to claim 1, 
Marques teaches the rules can be defined in any language," and infers from this that Marques 
therefore teaches the use of Rule-Based Markup Language ("RBML") documents. This is 
incorrect. 

Marques does not teach that rules can be defined in any language. In fact, the section 
referred to by the Office Action merely states that the "Troubleshooter" program, the overall 
program and not rules to define what the program does, has been implemented in several (not 
any language) programming languages {Troubleshooter is a collection of many programs and is 
implemented in several different programming languages) [see the discussion he ginning at Page 
13, col. 1 f3]. Additionally, there is no discussion at all in Marques regarding the language used 
to define rules, so it is impossible for Marques to teach the distinct requirement of the use of 
applicants' Rule-Based Markup Language to define and store a set of rules. 
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RBML is a markup language based on XML, and executes with the assistance of a 

program written in a different language. Since the Marques states only that "Troubleshooter" 

has been implemented in several languages, and "Troubleshooter" cannot be implemented using 

RBML, Marques does not describe the use of RBML to define and store rules. 

Furthermore, since XML was introduced in 1996, Marques, a 1988 article, cannot 

directly teach or suggest the use of RBML in any way. SGML, the predecessor to XML had 

been introduced as a first draft in 1980, but no reference to SGML is found in Marques. Not 

only does Marques fail to teach the use of RBML, but it fails to teach the use of any RBML 

predecessors. 

Finally, applicants' specification identifies other languages that have been used to define 
rules. The specification states in Paragraph 32 that "in various embodiments, RBML is 
implemented directly by a network management system, or is converted to another language that 
is known to the network management system, such as the SMARTS InCharge model language, 
NetCool scripting language, etc." Languages used for such systems are generally proprietary. 
Thus, having the ability to choose a language to use does not in fact teach one to use a particular 
language. To the contrary, knowing that something can be created using any language 
obfuscates the advantage of using one language in particular. 

Using RBML documents to define rules allows the rules to be ported to other network 
management systems, reducing the requirement for vendors and network management experts to 
create rules in multiple languages. Further, network management tools often require the use of a 
specific language to import rules or require that the rule be programmed into the system. RBML, 
on the other hand, allows the creation of rules by those less familiar with the inner workings of 
the network management system. Marques states that once the knowledge is gathered from the 
experts, rules are "coded in the form of complex condition-action pairs referred to as production 
rules" and proceeds to share the English language version of some rules [see the discussion 
beginning at Page 8, col. 2 f4-6]. The implementation in Marques is not even simple enough to 
allow subject matter experts to create the rules, since complex coding was required. Since the use 
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of RBML solves a problem that the Marques system is burdened with, Marques certainly does 

not teach the use of RBML. 

Claim 1 further recites, "a symptom-event rule that defines a problem within the 
network." The Office action further asserts that Marques teaches a system-event rule that 
identifies as a symptom a particular event occurring within the network. This is incorrect. 

The passage relied upon by the Office Action merely states the input of the system and 
does not define the type of rule used (System input consists mainly of (i) symptom descriptions 
that either are reported to the help desk by network end-users, or are derived from network 
generated messages, and (ii) specific inquiries about the operational state of a designated 
component) [see the discussion beginning at Page 6, col. 1 f5]. The more primitive single type 
of rule used in Marques is a condition-action rule (After the knowledge acquisition process was 
completed for a given component, the resultant knowledge was coded in the form of complex 
condition-action pairs referred to as production rules, or simply rules) [see the discussion 
beginning at Page 8, col. 2 f4]. By contrast, Claim 1 recites two distinct types of rules: (a) a 
symptom-event rule; and (b) a problem-diagnosis rule. 

Marques describes a limited approach using rules that can only instruct the system to 
"perform action X if device is in service state Y." Only a "detect service state — > apply 
corrective action" rule is disclosed. Claim 1 allows the use of any defined symptom or 
combination of symptoms to trigger an event. Also, any event or combination of events can be 
used to define problems. While Claim 1 allows such control over what will trigger an event and 
what will not, Marques simply waits for a device to trigger an event - allowing no control. 

With the claimed approach, a network engineer may define a combination of symptoms 
that may even be proactive in nature and include the use of information from multiple healthy 
devices to trigger an event that, when compared against a problem-diagnosis rule may tell a 
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network administrator that the network will have a particular problem shortly if a proactive step 
is not taken. 

Further, Marques actually relies on the network administrator to receive messages from a 
help desk, user, or computer generated event and interpret the message before starting the 
troubleshooting process (After receiving a trouble ticket or other fault notification the user logs 
into the Trouble shooter host and invokes the symptom via simple command line) [see the 
discussion beginning at Page 10, col. 1 fl]. In fact, the "Troubleshooter" does not even detect 
the address of the malfunctioning device - it must be provided by the network administrator 
before any "troubleshooting" begins (In order to trace the communications path, the system must 
be supplied with a starting point, which is the physical address where the end-user terminal 
enters the network.) [see the discussion beginning at Page 11, col. 1 fl]. The embodiment 
recited in Claim 1 has no such requirement of the network administrator because of the 
symptom-event rule. Marques cannot teach this feature. 

Claim 1 further recites "a problem diagnosis rule that defines a problem within the 
network as a correlation between one or more symptoms" and "applying the problem-diagnosis 
rule to symptom-related data." The Office Action asserts that Marques "teaches a problem- 
diagnosis rule that is defined based off of symptoms" and that Marques teaches applying the 
solution rule to the problem, inferring that Marques teaches applying a problem-diagnosis rule. 
These assertions are incorrect. 

The single rule used in Marques does not rely on symptoms; it relies on service state 
information coupled with human knowledge. In Marques, service state information, problems 
reported by users, and trouble tickets alert the network administrator to a possible problem. The 
network administrator then decides what the problem is and selects that particular problem from 
a menu in the "Troubleshooter" application. The network administrator then inputs the address 
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of the device suspected to be at issue. Once the proper information is collected from the network 
administrator, the troubleshooting begins. The "Troubleshooter" program does not actually 
monitor the network; it "checks" the network when told to do so. Even in the most automated 
alternative mode, the "Troubleshooter" still "prompts [the administrator] for a symptom 
description and the physical address of the component to be diagnosed." [see the discussion 
beginning at Page 12, col. 2 f7]. In contrast, Claim 1 allows greater flexibility without the strict 
requirement for human intervention. 

Marques describes applying a solution to the detection of a service state. Marques does 
not teach applying a problem-diagnosis rule. Marques provides no way to detect one or more 
symptoms that constitute an event or correlate the events as a problem. These symptoms and 
events may be defined by any user of the system, and may have nothing to do with the service 
state of a device. Further, multiple devices may take part in the determination of a problem. 
Marques only describes a method of troubleshooting the cause of a problem for a single device 
by entering the address of that one device. In contrast, Claim 1 "monitors the network for one or 
more network events identified in the symptom-event rule." Claim 1 further recites that 
"detecting a problem includes applying the problem-diagnosis rule to the symptom-related data." 
Since symptom-event rules and the problem-diagnosis rules are defined by the user with RBML, 
they are not limited to the number or type of network events they encompass. This flexibility is 
a strong distinction between Claim 1 and Marques. 

For the last two steps of Claim 1, the Office action asserts that Marques "teaches 
collecting symptoms by monitoring the network" and "detecting a problem within the network." 
This is incorrect. 

The troubleshooting system discussed in Marques does not monitor the network. The 
"Troubleshooter" only "checks" the network when told to do so. Furthermore, the 
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troubleshooting system discussed in Marques does not detect a problem within the network 

without the help of human intervention, as discussed. 

For at least the foregoing reasons, Claim 1 is not taught in full by Marques and is in 

condition for allowance. Therefore, removal of the rejection under 35 U.S.C. § 102(b) is 

respectfully requested. 

CLAIMS 11, 15,22, and 32 

The Office Action stated the same reasons in rejecting Claims 11, 15, 22 and 32 to those 
in rejecting present Claim 1. Claims 15, 22 and 32 recite the same features discussed above that 
make Claim 1 patentable over Marques. Therefore, for at least the same reasons set forth above 
by the Applicant in connection with present Claim 1, it is respectfully submitted that each of 
Claims 11,15, 22 and 32 is patentable over Marques under 35 U.S.C. § 102(b). 

DEPENDENT CLAIMS 

The claims not discussed thus far are dependent claims, each of which depends (directly 
or indirectly) on one of the independent claims discussed above. Each of the dependent claims is 
therefore allowable for the reasons given above for the claim on which it depends. In addition, 
each of the dependent claims introduces one or more additional limitations that independently 
render it patentable. However, due to the fundamental differences already identified, to expedite 
the positive resolution of this case, a separate discussion of those limitations is not included at 
this time. The Applicant reserves the right to further point out the differences between the cited 
art and the novel features recited in the dependent claims. 
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For the reasons set forth above, all of the pending claims are now in condition for 
allowance. The Examiner is respectfully requested to contact the undersigned by telephone 
relating to any issue that would advance examination of the present application. 

A petition for extension of time, to the extent necessary to make this reply timely filed, is 
hereby made. If applicable, a check for the petition for extension of time fee and other applicable 
fees is enclosed herewith. If any applicable fee is missing or insufficient, throughout the 
pendency of this application, the Commissioner is hereby authorized to any applicable fees and 
to credit any overpayments to our Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Dated: July 2. 2007 /ChristopherJPalerrno#42056/ 

Christopher J. Palermo 
Reg. No. 42,056 

2055 Gateway Place Suite 550 
San Jose, California 95110-1093 
Telephone No.: (408) 414-1080 
Facsimile No.: (408) 414-1076 
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